1. Field of Invention
The invention relates generally to methods and apparatuses for implementing name services in distributed object systems. More particularly, the invention relates to methods and apparatuses for implementing CORBA compliant name services.
2. Description of Relevant Art
Name services are often implemented within distributed object systems to enable distributed objects to be readily identified. One type of a distributed object system which uses name services includes a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification produced by OMG. Distributed object systems which use name services may be in the context of an Object Request Broker (ORB) implemented under the CORBA specification from the OMG, Revision 2.0, Revision 2.1, Revision 2.2 and Revision 2.3, all of which are incorporated herein by reference in their entirety. Specifically, the xe2x80x9cCosNamingxe2x80x9d module of the CORBA Services specification, as specified in the CORBA specification from the OMG, may be used to implement name services. For purposes of this application, programs compliant with CORBA Revision 2.3, 2.2 , and 2.1, by definition will be viewed as compliant with CORBA Revision 2.0. Unless otherwise specified, a generic reference to the CORBA Services specification will be presumed to be OMG""s CORBA Services Revision 2.0. The components of the CORBA Services specification detailed above which address name services will be referred to hereinafter as the CORBA CosNaming Specification.
A name service, which may be associated with a name server, is typically arranged such that, when provided with a name, the name service associates the name with xe2x80x9csomething,xe2x80x9d e.g., an object, an object reference, or a property. The association of the name with an object, for example, may either be transient or persistent. For a transient name service, the association between a name and an object generally disappears once the program which implements the name service terminates. Alternatively, for a persistent name service, the association between a name and an object is stored in a data file, and does not disappear once the program which implements the name service terminates. In general, the implementation of a name service often includes the implementation of a data structure such as a table (or hash table) to hold bindings between names and object references and, in some cases, properties. Such a data structure, in other words, may be used to associate names with object references, as well as properties. Such a data structure is maintained in a data store and accessed through a data store interface, where such data store may be persistent or transient.
Both U.S. Pat. No. 6,044,379 to Callsen, issued Mar. 28, 2000 for xe2x80x9cMethod and apparatus for efficiently implementing multiple storage mechanism for name services associated with a computer systemxe2x80x9d and U.S. Pat. No. 5,873,092 to Cheng, et al., issued Feb. 16, 1999 for xe2x80x9cInformation handling system, method, and article of manufacture including persistent, distributed object name services including shared propertiesxe2x80x9d address efforts to improve naming services and provide detailed background information known to those of skill in the art regarding the operations of naming services. Both of these patents are incorporated herein by reference.
A typical implementation of a name service includes a xe2x80x9cmainxe2x80x9d table. Although the main table may take on a variety of different configurations, the main table is typically a look-up table, or a list, which associates names in a name column of the main table with references in a reference column of the main table. References in the reference column identify, or reference, objects which are associated with names. By way of example, name xe2x80x9cXxe2x80x9d is associated with reference xe2x80x9cx.sub.pxe2x80x9d, which is a reference to a specific object. As such, reference xe2x80x9cx.sub.pxe2x80x9d is essentially an object reference which identifies the specific object. A reference is also referred to as an object reference or simply a reference, which in a CORBA compliant system is typically a relatively extensive IOR. The use of a name service enables a name, such as name xe2x80x9cXxe2x80x9d, to be remembered, instead of reference xe2x80x9cx.sub.pxe2x80x9d, when access to the specific object is desired. By using a name as an index into the main table to identify an object, the overhead, and, hence, the complexity associated with locating objects can be reduced.
A look-up table, which is included as a part of a name service, may either be transient or persistent. For a transient name service, local look-up tables, i.e., look-up tables which were created locally during a process, are temporarily stored in volatile memory, and are not stored into a file. As such, when a program which implements the local look-up tables terminates, the local look-up tables, in addition to information contained in local look-up tables, is destroyed. Alternatively, for a persistent name service, the local look-up tables are stored into files, as for example files on a non-volatile memory, such as a disk. Hence, data contained in look-up tables associated with a persistent name service is not destroyed when the program which implements the look-up tables is terminated.
A name may generally be expressed as an array of name components. In a CORBA compliant system, each of the name components comprises a pair of strings (the id string and the kind string). In other words, although a name may be expressed as xe2x80x9c/a/b/c/dxe2x80x9d (or even xe2x80x9cabcdxe2x80x9d), when a name is to be processed, e.g., bound or resolved, the name is typically processed as an array of components [a, b, c, d], and for illustrative purposes will be referred to in this fashion. When the name [a, b, c, d] is being xe2x80x9clooked up,xe2x80x9d or resolved, using a name service, the components of the name are looked up sequentially. The first component of the name, i.e., xe2x80x9ca,xe2x80x9d is resolved first, while the last component of the name, i.e., xe2x80x9cd,xe2x80x9d is resolved last. For example, a name service implementation may include multiple look-up tables which may be used to identify a reference to an object that is associated with and, hence, may be identified by name [a, b, c, d]. Such a name service implementation could include a main look-up table which is used to associate a reference xe2x80x9ca.sub.pxe2x80x9d with a first component xe2x80x9caxe2x80x9d of name [a, b, c, d].
Reference xe2x80x9ca.sub.pxe2x80x9d identifies a second look-up table in which a second component xe2x80x9cbxe2x80x9d of name [a, b, c, d] may be found. Second component xe2x80x9cbxe2x80x9d is associated with a reference xe2x80x9cb.sub.pxe2x80x9d which identifies a third look-up table. The third look-up table is used to find a third component xe2x80x9ccxe2x80x9d of name [a, b, c, d], which is associated with a reference xe2x80x9cc.sub.pxe2x80x9d that references a final look-up table. In this example, the final look-up table is the last in a chain of look-up tables associated with name service implementation. However, as will be appreciated by those skilled in the art, the number of look-up tables associated with a name is often dependent upon the number of components in the name.
The final look-up table associates, e.g., binds, component xe2x80x9cdxe2x80x9d of name [a, b, c, d] with a reference xe2x80x9cO.sub.ptrxe2x80x9d. In other words, when name [a, b, c, d] is traversed until only component xe2x80x9cdxe2x80x9d remains, component xe2x80x9cdxe2x80x9d may then be bound to reference xe2x80x9cO.sub.ptrxe2x80x9d which references an object which is associated with the overall name xe2x80x9cabcd.xe2x80x9d When the name service stores look-up tables, either in volatile memory or in non-volatile memory, the four tables are all stored. As will be appreciated by those skilled in the art, typically, either all or none of tables are stored. When all tables are stored, by way of example, the first table is either temporarily stored in volatile memory, such that the first table is destroyed when the program that implements the name service implementation terminates, or the first table is written into a file on a disk. In other words, for a transient name service, the first table is stored in volatile memory, whereas for a persistent name service, the first table may be stored on a disk. By analogy, the other tables are stored in the same manner.
Some name services may also store properties in look-up tables. For example, the final look-up table may include references to a property table which contains a property that is associated with name [a, b, c, d]. A reference xe2x80x9cpropxe2x80x9d associated with name [a, b, c, d] may identify a property table which contains properties and may, in some instances, also include objects.
The data from the various look-up tables is stored in a data store or a group of data stores, which may be transient or persistent, as discussed above. Information or data is placed into and retrieved out of the data stores by a data store interface. To the extent the prior art addresses the use of persistent data stores to support name services, the prior art has focused on the use of relational databases as the primary vehicle for data storage.
In other areas of programming, alternative methods do exist to the use of relational databases as data stores. One alternative is the use of flat files. Another alternative is the use of directory services. One standardized method of implementing directory services, and data store interfaces to interact with directory services, is the use of the Lightweight Directory Access Protocol version 2, the specification of which is incorporated herein by reference in its entirety. Hereinafter, when discussing this specification, it may also be referred to as LDAP version 2. LDAP version 3 also may be used and its specification is also herein incorporated by reference. LDAP is used as a generic designation for interfaces and protocols compliant with a version of the Lightweight Directory Access Protocol. For purposes of this application, by definition any server or interface which is compliant with LDAP version 3 would also be viewed as compliant with LDAP version 2. The converse is not necessarily correct.
The invention comprises methods and apparatus for implementing a name service. According to the present invention, a name service which is compliant with the CORBA CosNaming Specification incorporates load balancing features. One embodiment may be implemented by creating a name service arranged to store information, creating a data store within the name service to store the information, and creating a data store interface within the name service to interact with the data store to store and retrieve the stored information. This embodiment additionally involves creating a load balancing index within the data store interface, and using name-overloading to create names containing a load balancing name identifier in the name component of the names. The load balancing identifier is a subset of the name component of the names and may be used for referencing in the load balancing index. Finally, this embodiment involves storing names containing a load balancing identifier in the load balancing index in a form which may be referenced by the load balancing identifiers of the respective names. The data store of the above-described embodiment could comprise a transient data store, a persistent data store, or both. In one alternative embodiment using a persistent data store, the persistent data store comprises a directory service. In a more specific embodiment, the directory service is compliant with LDAP version 2 and the interaction between the data store interface and the persistent data store comprises the use of protocol compliant with LDAP version 2. The data store interface of this method could also include a specific bind operation, a specific resolve operation, or both.
One embodiment of this invention involving the data storage interface focuses on a bind operation. The method for binding a name includes receiving the name and the object reference and binding the name with the object reference. The method also determines whether the name participates in load balancing and, if it does, adds the name to a load balancing index.
Another embodiment involving the data storage interface focuses on a resolve operation. The method for resolving a name includes receiving the name and determining whether the name participates in load balancing. If the name participates in load balancing, then the operation determines the entry in the load balancing index to return and returns the object reference associated with the determined entry from the load balancing index.
In a more detailed embodiment incorporating rudimentary fault tolerance, the action of determining the entry to return is made up of several additional actions. First, the resolve operation preliminarily identifies a responsive entry in the load balancing index and then checks to see if the object reference associated with the preliminarily identified entry is existent. If the preliminarily identified entry is existent, then the operation determines the preliminarily identified entry as the determined entry which is then returned by the last action of the resolve operation. If the previous preliminarily identified entry is not existent, then the operation preliminarily identifies the next responsive entry in the load balancing index and repeats the actions of checking, determining, and preliminarily identifying so long as unchecked responsive entries remain in the load balancing index and an existent entry has not been determined. Finally, if no unchecked responsive entries remain in the load balancing index, then the operation determines a responsive entry as the determined entry. In the preferred version of this embodiment, if no unchecked responsive entries remain in the load balancing index then the operation determines the last preliminarily identified entry as the determined entry.
A different embodiment of the invention encompasses a name service within a computer system. The name service is arranged to store information and includes both a data store within the name service to store the information and a data store interface within the name service. The data store interface is compliant with CORBA CosNaming Specification and interacts with the data store to store and retrieve the stored information. This embodiment further includes a load balancing index within the data store interface and name-overloaded names which contain load balancing identifiers within the name components of the names which may be used for referencing in the load balancing index. In this embodiment, the name-overloaded names containing load balancing identifiers are stored in the load balancing index in a form which may be referenced by the load balancing identifiers of the respective names.
An additional embodiment of this invention takes the form of a computer system arranged to implement a name service. The computer system includes a processor, a data store within the name service to store the information, and a data store interface within the name service. The data store interface is compliant with CORBA CosNaming Specification and is designed to interact with the data store to store and retrieve the stored information. The computer system additionally includes a load balancing index within the data store interface and name-overloaded names which contain load balancing identifiers which may be used for referencing in the load balancing index. In this embodiment, the name-overloaded names containing load balancing identifiers are stored in the load balancing index in a form which may be referenced by the load balancing identifiers of the respective names.
Finally, an embodiment of the invention may be described as a computer program product for implementing a name service. The computer program product includes computer code that creates a name service arranged to store information, computer code that creates a data store within the name service to store the information, and computer code that creates a CORBA compliant data store interface within the name service to interact with the data store to store and retrieve the stored information. The computer program product of this embodiment additionally includes computer code that creates a load balancing index within the data store interface, computer code that recognizes name-overloaded names which contain load balancing identifiers in the name components of the names, and computer code that stores names containing a load balancing identifier in the load balancing index in a form which may be referenced by the load balancing identifiers of the respective names. Finally the computer program product includes a computer readable medium that stores the computer codes, where in one alternative embodiment the computer readable medium is a code representation embodied in a carrier wave.